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Abstract 

Simulation-based assertional techniques and process algebraic techniques are two of the 
major methods that have been proposed for the verification of concurrent and distributed 
systems. It is shown how each of these techniques can be applied to the task of verifying 
systems described as input/output automata; both safety and liveness properties are con- 
sidered. A small but typical circuit is verified in both of these ways, first using forward 
simulations, an execution correspondence lemma, and a simple fairness argument, and sec- 
ond using deductions within the process algebra DIOA for I/O automata. An extended 
evaluation and comparison of the two methods is given. 



1 Introduction 

Simulation-based assertional techniques and process algebraic techniques are two of the major 
methods that have been proposed for the verification of concurrent and distributed systems. 
Although the two methods are used for the same task, the proofs that are carried out in the 
two styles seem to be quite different. Indeed, the two methods have been developed by largely 
disjoint research communities, using different semantic models. The literature contains many 
examples of proofs using the two methods: some typical examples of simulation proofs appear 
in [LT87, SLL93a, SLL93b], while examples of algebraic proofs appear in [Bae90, Jos92, OP92]. 

In this paper, we unify, evaluate and compare the simulation-based and process algebraic 
verification techniques in terms of the Input /Output automaton (I/O automaton) model of 
Lynch and Tuttle [LT87]. This framework has been used extensively for the verification of 
complex algorithms and pieces of distributed systems [WLL88, LS92, LP92, SLL93b], and 
has already been given a process algebraic characterization [Vaa9I, Seg92, DS92]. We show 
how each of these techniques can be applied to the common task of verifying both safety 
and liveness properties of systems described as I/O automata. We then use each technique 
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to verify a small but typical delay insensitive circuit taken from [Jos92]: a Muller C element 
[MB59] implemented in terms of a majority element and a wire. Both the implementation and 
the specification are described as I/O automata, and the verification consists of showing that 
the fair preorder relation (i.e., fair trace inclusion) holds between the implementation and the 
specification automata. 

The two proofs proceed very differently. First, the simulation proof uses a forward simula- 
tion [LV91] from the implementation to the specification, then invokes an execution correspon- 
dence lemma [GSSL93] to obtain a correspondence between executions of the implementation 
and the specification. Then a simple argument about fairness is made, based on the corre- 
spondence between executions; this fairness argument uses the convenient notion of a forcing 
condition for an I/O automaton fairness class. The fairness argument could easily be formal- 
ized using a temporal logic of states and actions [Sta84, SLL93b], although we do not do this 
in this paper. 

The algebraic proof uses deductions within the process algebra DIOA [Seg92] for I/O au- 
tomata. This process algebra contains a collection of axioms (i.e., sound proof rules) asserting 
that the quiescent preorder relation holds for a pair of I/O automata. The quiescent preorder 
is defined in [Vaa91] and consists of trace inclusion and quiescent trace inclusion. It is an 
approximation, based on finite traces only, of the fair preorder. The reason for the use of the 
quiescent preorder rather than the fair preorder is that quiescence fits nicely into a process 
algebraic theory containing recursion whereas fairness does not. We state conditions (proved 
in [Seg93]) giving some circumstances under which the quiescent preorder is equivalent to the 
fair preorder. Since these circumstances hold in our example, the DIOA deductions that prove 
quiescent trace inclusion are also sufficient to prove the needed fair trace inclusion. 

We emphasize that our two proofs are constructed to prove exactly the same theorem. To 
make this clear we first give a "neutral" description of the verification problem in terms of I/O 
automata. Then we describe and verify the same problem in terms of an assertional repre- 
sentation of I/O automata and in terms of DIOA expressions, using simulation and algebraic 
techniques, respectively. We show formally that the two proofs are both solving the problem 
given in the "neutral" description. This last step is essential in order to ensure sure that, 
although we are using different formalisms, we are actually solving the same problem. 

We then give an extended comparison of the two verification methods, based on our ex- 
periences in carrying out this research and on our other experiences with related examples. 
Our comparisons consider the power of the two methods, their ability to model fairness, the 
style of their representation of system components, their suitability for mechanization, and the 
byproducts yielded by the proofs. 

The rest of the paper is organized as follows. Section 2 contains a brief description of the 
I/O automaton model. Section 3 contains a formal statement of the circuit problem to be 
solved, i.e., showing that the fair preorder relation holds between a particular implementation 
and a Muller C element specification. Section 4 contains the verification using the simulation 
method. Section 5 contains the verification using process algebra. Section 6 contains an 
extended comparison between the two methods; Section 7 contains some additional conclusions. 



2 The Input/Output Automaton Model 

We begin with a brief review of the I/O automaton model, which will be used as the basis of 
the rest of the work in this paper. For a complete account, we refer the reader to [LT87]. 

Definition 2.1 (Notation for sequences) Given an alphabet A, let A* be the set of finite 
length sequences made of elements of A and let A° be the set of infinite length sequences made 
of elements of A. Finally, let A* U A° be denoted by A°° . ■ 

Definition 2.2 (I/O automata) An I/O automaton A consists of five components: 

• a set states(A) of states. 

• a nonempty set start(A) C states(A) of start states. 

• an action signature sig(A) = (in(A),out(A),int(A)) where in(A), out(A) and int(A) are 
disjoint sets of input, output and internal actions, respectively. We denote with ext(A) 
the set in(A) U out(A) of external actions, and by local(A) the set out(A) U int(A) of 
locally controlled actions. We denote by acts(A) the set ext(A) U int(A) of actions. We 
call (in(A), out(A), 0) the external action signature of A. 

• a transition relation steps(A) C states(A) X acts(A) X states(A) with the property that 
for each state q and each input action a there is a step from q with action a. We say 
that A is input enabled. 

• A partition part(A) of local(A). 

A transition (q,a,q r ) £ steps(A) is also denoted with q — > q 1 . We extend the notion of 
transition to finite sequences of symbols by saying that 

q - — ►" q' iff 3q , . . . , q n with q = q and q n = q' such that q — ^ qi —^ ■ ■ ■ —^ q n . 

Similarly, for infinite sequences, we write 

g — > it d(gj) JG jv sucn that q — ► g! — ► g 2 — ► • • • 

Two derived transition relations, abstracting from internal computations, are 

a, / -rr n S]_as 2 / 

<1 ==> <1 m d SlS2Gint .(^)g — ^ q , 

g ==>- g lit d Sieint . (A) g — > q . 

The last two transition relations can be extended to finite and infinite sequences of actions in 
the same way as for steps(A). ■ 



Definition 2.3 (Executions and traces) An execution fragment of an I/O automaton A is 
a (finite or infinite) sequence of alternate states and actions starting with a state and, if the 
execution fragment is finite, ending in a state 

a = q a 1 q 1 a 2 q 2 ■ ■ ■ 

where each (g 8 , a J+1 , g J+1 ) £ steps(A). We denote by frag* (A) , frag w (A) and frag(A) the sets 
of finite, infinite and all execution fragments of A, respectively. An execution is an execution 
fragment whose first state is a start state. We denote by exec* (A), exec w (A) and exec(A) the 
sets of finite, infinite and all execution of A, respectively. 

The trace of an execution fragment a of an I/O automaton A, written trace A (a), or just 
trace(a) when A is clear, is the list obtained by projecting a onto the set of external actions of 
A, i.e., trace(a) = a\ext(A)} We say that (3 is a trace of an I/O automaton A if there exists 
an execution a of A with trace(a) = (3. We denote by traces* (A), traces w (A) and traces(A) 
the sets of finite, infinite and all traces of A, respectively. ■ 

A key feature of the I/O automaton model is that the behavior of I/O automata is observed 
through their fair executions, i.e., those executions in which each "subcomponent" which is 
continuously willing to perform some of its locally controlled actions will eventually do so. 

Definition 2.4 (Fair executions) A fair execution fragment of an I/O automaton A is an 
execution fragment a £ execs(A) such that for all X £ part(A) 

• If a is finite then no action of X is enabled from the final state of a. 

• If a is infinite then either actions from X appear infinitely often in a or states from 
which no action of X is enabled appear infinitely often in a. 

A fair execution is a fair execution fragment whose first state is a start state. A fair trace 
is the trace of a fair execution. We denote the set of fair traces of an I/O automaton A by 
ftraces(A). ■ 

Now we can define the usual preorder relation for I/O automata. 

Definition 2.5 (Fair preorder) Given two I/O automata A and B with the same external 
action signature, the fair preorder is defined as 

A \Z F B iff ftraces(A) C ftraces(B). ■ 



Our definition of trace coincides with the usual definition of behavior for I/O automata. We have changed 
the terminology in the interests of consistency with the usual notation of process algebra. 



The fair preorder is the relation that is used to model implementation in the I/O automa- 
ton model. Since input enabling ensures that any implementation must accept any external 
stimulus at any time, this preorder ensures that the implementation must contain a "rich" 
set of traces - enough to describe responses to any possible input pattern. Fairness ensures 
that the correctness of a solution is judged only on the basis of those behaviors in which the 
system is actually given the chance to make progress. Note that this preorder ensures that the 
implementation must provide output whenever the specification must do so. 

Three main operators are defined on I/O automata: hiding, renaming and parallel compo- 
sition. 

Definition 2.6 (Hiding) Given an I/O automaton A = (Q,Q ,S,t,P) and a set of actions 
/ : Inin(A) = 0, we define Hidej(A) to be the I/O automaton (Q,Q ,S',t,P) where S' differs 
from S in that 

• out(Hide I (A)) = out(A)\I, and 

• int(Hide I (A)) = int(A) U (acts(A) n I). ■ 

The hiding operator transforms external actions into internal ones, i.e., it hides some locally 
controlled actions from the external environment. The only difference between the original 
and the resulting I/O automaton is in the signature. The executions stay the same, but the 
traces change. 

Definition 2.7 (Renaming) An injective mapping / is applicable to an I/O automaton A if 
acts(A) C dom(f). Given an I/O automaton A = (Q,Q ,S,t,P) and a mapping / applicable 
to it, we define f(A) to be (Q,Q ,S',t',P') where S',t' and P' are defined as follows 



in(S) = f(in(A)), out(S) = f(out(A)), int(S) = f(int(A)), 
t = {(q, f(a),q') : (q,a,q') G steps(A)}, and 
P = {(f(a)J(a')):(a,a')e P art(A)}. 



Thus, the renaming operator simply renames actions of its operand. For the parallel compo- 
sition we need a notion of compatibility for action signatures. 

Definition 2.8 (Strong compatibility of I/O automata) 

1. A set of action signatures {Si : i G 1} are strongly compatible iff for all i,j £ I 

(a) out (Si) fl out(Sj) = 0, and 

(b) int(Si) n acts(Sj) = 0. 



2. A set of I/O automata {A; : i G 1} are strongly compatible iff their action signatures are 
strongly compatible. ■ 

Definition 2.9 (Composition of I/O automata) The composition A = Yl i€l A; of strongly 
compatible I/O automata {A; : i G i"} is defined to be the I/O automaton with 

1. states(A) = Yl i€l states(Ai), 

2. start(A) = J7siarf(A;), 

i£l 

3. sig(A) = Uiei si 9( a i), 

where composition S = Yliei ^ °f strongly compatible action signatures {Si : i £ 1} is 
defined by 

(a) in(S) = U,. e/ m(,S',-) - U,- e / out(Si), 

(b) ok^) = Uig/ow^^-), 

(c) int(S) = [j i€l int(Si), 

4. pari(A) = U,- e /Pari(A,-), 

5. steps(A) = { ((qi)i € i,a,(q^) i€l ) : Vi G / 

a G acis(Aj) implies (qi,a,q^) G sieps(A 8 -), a ^ acis(A 8 -) implies q, = g 8 '} ■ 

3 The Problem 

In this section, we define the problem that we are going to solve using both the simulation 
and algebraic methods. This problem is that of verifying the correctness of a particular circuit 
implementation. We begin with an informal description, then present the formal version in 
several pieces. 

3.1 Informal Description 

The example consists of a simple delay insensitive circuit, taken from [Jos92], called the Muller 
C element [MB59]. Its interface is shown in Figure 1. A Muller C element has two input ports 
a, b and one output port c. Once it is in its initial state with all input and output voltage 
levels low, a Muller C element waits for both its inputs to reach the high voltage level for then 
raising its output voltage level. It then waits for both its inputs to reach the low voltage level 
for then reaching again its initial state. In our specification no changes on the input ports are 
allowed whenever the voltage level of an output port has to change. Real implementations may 
exhibit unexpected behaviors (such as the glitch phenomenon) in such cases. For the above 




Figure 1: The Muller C element 




Figure 2: A majority element and a wire implementing a Muller C element 



reason we do not specify the behavior of any element whenever an output voltage level has to 
change and an input occurs. 

A Muller C element can be implemented by a majority element and a wire as shown in 
Figure 2. A majority element is a device with three input ports and one output port. The 
voltage level of its output port is that of the majority of its input ports. For the majority 
element we allow the change of level of an input port even if the output port has to change 
level. The required condition is that the new input does not affect the ports that have to 
change voltage level. 

A wire is simply a device with one input and one output. It waits for a change of level on 
its input port for then changing the voltage level of its output port. 

Our problem is to verify that a Muller C element can really be implemented by a majority 
element and a wire. 



3.2 Formal Description 

3.2.1 Actions as Voltage Level Transitions 

In our formalization we use actions to model changes of voltage level (either from low to high or 
from high to low) at a port. The observation of an action does not give any information whether 
the voltage transition is from high to low or vice versa. Our use of actions is a consequence of 
the fact that the elements of the problem we are analyzing can be simply described in terms 
of voltage level transitions. 

3.2.2 Specifications of the Elements 

The specification S of an element is a tuple (Q, Q , S, T, P) consisting of a set of states Q, a set 
of start states Q , an interface S consisting of three disjoint sets of input, output and internal 
actions respectively, a transition table T, and a partition of the locally controlled actions P. 
The transition table gives, for each state and action, the future state, or not specified (NS), 
or not enabled (NE). The entry not specified is reserved for input actions and stands for "the 
environment is not supposed to provide input at this point"; the entry not enabled is reserved 
for local actions and stands for "this action cannot occur at this point". 

The specification style outlined above does not define I/O automata directly, however it 
allows specifications that are very close to the informal specifications of Section 3. Later in 
this section we will formally define how to interpret the specifications below as I/O automata. 
The Muller C element, the wire and the majority element specifications are denoted by Cjv, 
Wjm and Mjv, respectively. Here, N stands for "neutral" in the sense these specifications are 
not biased toward either of the representation methods or verification techniques we introduce 
later. We start with the formal specification of a Muller C element. 

Specification 3.1 (Muller C element) A Muller C element Cjv is defined as follows. 

5 = ({a,6},{c},0) 
Q = {0, {«},{&},{«,&}} 
Qo = {0} 
P = {{c}} 

The transition relation is defined by the following table: 
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{a, b} 


NE 
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{a, b} 
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{a, b} 


NS 


NS 






It is easy to check that the above specification corresponds to the informal one given in Sec- 
tion 3. Starting from a state where the voltage level of each port is the same (say low), the 
occurrence of an input action would cause the system to move to a new state in which the new 
voltage level of the given input port is considered. When the voltage level of both the input 
ports is different from the voltage level of the output port (state {a, b}) the output action c is 
enabled and no input is allowed to occur. 

Specification 3.2 (Wire) A wire Wjm is defined as follows. 

5 = ({m},{c},0) 
Q = {A, to} 
Qo = {A} 
P = {{c}} 

The transition relation is defined by the following table: 
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NS 


NE 
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Specification 3.3 (Majority element) A majority element M N is defined as follows. 

5 = ({a,6,c},{m},0) 
Q = 2 {a ' h ' c} 

Qo = {0} 
P = {{m}} 

The transition relation is defined by the following table: 
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3.2.3 From Specifications to I/O Automata 

The formal specifications of Section 3.2.2 are not I/O automata since their transition relations 
are not input enabled. In particular it is necessary to define carefully the meaning of the two 
special symbols NE and NS. The meaning of NE is trivial since T(q, a) = NE for a state q and 
an output action a means that no transition with action o occurs from state q. If T(q, a) = NS 
for a state q and an input action a, then, since an I/O automaton is input enabled, a transition 
from q with action a must be defined. Intuitively we do not wish to constrain the behavior 
of any implementation in the presence of an unspecified input. In other words we want any 
implementation to be correct independently of the behaviors it exhibits in the presence of 
some input that is not specified in the specification. Since the implementation relation of I/O 
automata is the fair preorder, the above intuition is captured by introducing a new special state 
0, and, whenever T(q,a) = NS, by introducing a transition q — ► S7. The transition relation 
on S7 has to be defined in such a way that, given any sequence of actions (3, it is possible to 
find a fair execution fragment a whose first state is S7 and such that trace(a) = (3. 

Definition 3.4 (Automaton associated with a specification) Given a specification S = 
(Q,Q ,(in,out,int),T,P) the I/O automaton A = A(S) is defined as 



• 



• 



• 



• 



• 



states(A) = Q U {&}. 

start(A) = Q . 

sig(A) = (in, out, int U {t p \ p £ i 5 })- 

(q,a,q r ) £ steps(A) iff 

— T(q, a) = q 1 or 

— T(q, a) = NS and q 1 = S7 or 

— q = q' = 0. 

part(A) = {p U {t p } \ p £ P}. 



The following proposition shows that everything is possible whenever S7 is reached, i.e., any 
choice of implementation is correct whenever the specification reaches state S7. 

Proposition 3.5 Given a specification S and given any (possibly infinite) sequence (3 of ex- 
ternal actions of S there exists a fair execution fragment a of A(S) whose first state is S7 such 
that trace(a) = (3. 

Proof. The execution fragment a interleaves the actions of (3 with one internal action from 
each class of part(A(S)). If (3 is finite then a fairly loops forever on the internal actions from 
each class of part(A(S)) after (3 is completed. By construction we know that each class has at 
least one internal action. Moreover S7 has a self loop with each action. ■ 

Now we can state the problem formally: verify that 

Hide {m] (A(M N ) || A(W N )) Q F A(C N ). 

10 



4 A Verification using Simulation 

In this section we carry out the verification required in Section 3.2 using simulation-based 
assertional techniques. We begin by presenting the relevant theory, then give variants of the 
specifications of Section 3.2 that are better suited for carrying out a simulation proof, and 
finally carry out the steps of the proof. 

4.1 The Theory 

In order to prove that an I/O automaton A implements another I/O automaton B, it is 
necessary to prove that each fair trace of A is also a fair trace of B. Our strategy for doing this 
is to first obtain a strong correspondence between each execution of A and some execution of 
B; one way of obtaining such a correspondence is by using a forward simulation. The proof of 
fair trace inclusion can then be carried out in terms of the correspondence between executions. 

In the fairness proof, it is notationally advantageous to use a generalization of I/O automata 
known as forcing I/O automata; this generalization does not increase the expressive power of 
the model, but does allow more concise representations. 

Below, we define forward simulations, state the Execution Correspondence Lemma, and 
give the needed definitions are results for forcing I/O automata. 

4.1.1 Forward Simulations and the Execution Correspondence Lemma 

The notion of forward simulation that we use is taken from the comprehensive paper by Lynch 
and Vaandrager [LV91]. 

Definition 4.1 (Forward simulation) A forward simulation from an I/O automaton A to 
an I/O automaton B is a relation / over states(A) and states(B) that satisfies: 

1. If q £ start(A) then f[q] n start(B) ^ 0. 

2. If q — ► q 1 and p £ /[<?], then there exists a state p' £ /[<?'] such that p =>■ p' . ■ 

The usual conclusion that is drawn from the existence of a forward simulation is trace inclusion: 

Lemma 4.2 Given two I/O automata A,B, if there is a forward simulation from A to B, 
then traces(A) C traces(B). ■ 

However, since we would like to base our proof of fair trace inclusion on our proof of trace 
inclusion, it is useful to have a stronger consequence of the existence of a forward simulation. 
This lemma is proved in [GSSL93]. 2 



In [GSSL93], it is also shown that a similar lemma holds for other types of simulation relations such as 
backward simulations. 

11 



Lemma 4.3 (Execution correspondence) Let f be a forward simulation from an I/O au- 
tomaton A to an I/O automaton B. Then, for each execution a = g a i?i a 2?2 • • • °f A 
there is an execution a' = q' biq' 1 b2q' 2 • • • of B and a total monotone nondecreasing mapping 
c : {0, . . ., \a\} — ► {0, . . ., |a'|} such that 

1. c(0) = 0, 

2. q' c(i) £ f(qi) for allO <i< \a\, 

3. & c (i)+i ' ' 'b c (i+i)\ext(B) = a i+ i\ext(A) for all < i < \a\, and 

4- for all q'j there exists an i such that c(i) > j . ■ 

If the forward simulation is well chosen, Proposition 4.3 can be used as the basis of a proof 
of fair trace inclusion, as follows. For each fair execution a of A, first produce a corresponding 
execution a' of B. Then show that the fairness of a implies the fairness of any corresponding 
execution of B. This is the general strategy we will follow in our proof. 

4.1.2 Forcing I/O Automata 

In carrying out the proof of fairness, it turns out to be notationally convenient to use a slight 
generalization of I/O automata that we call forcing I/O automata [SLL93b]. The generalization 
consists of associating a set of states called a forcing set with each class of part(A). Forcing 
I/O automata are no more expressive than ordinary I/O automata, in terms of the sets of 
fair traces they can represent; they are useful, however, because they sometimes admit more 
concise representations. 

Definition 4.4 (Forcing I/O automata) A forcing I/O automaton A is an I/O automaton 
with the following additional structure: 

• a function force(A) associating a set of states with each partition of part(A) such that, 
for each partition p £ part(A) and each state q £ force(A)(p), there exists an action of p 
which is enabled from q. The set force(A)(p) is called the forcing set of p. It is a subset 
of the states enabling some action of p. The set of states enabling some action from p is 
denoted by enabling(p). ■ 

The notion of fair execution for forcing I/O automata differ from that of ordinary I/O automata 
is that fairness is now expressed only with respect to states in the forcing set of each class p of 
local actions. 

Definition 4.5 (Fair executions) A fair execution fragment of a forcing I/O automaton A 
is an execution fragment a £ execs(A) such that for all X £ part(A) 

12 



• If a is finite then the final state of a is not in the forcing set of X . 

• If a is infinite then either actions from X appear infinitely often in a or states not in the 
forcing set of X appear infinitely often in a. 

A fair execution is a fair execution fragment whose first state is a start state. ■ 

The following proposition says that forcing I/O automata do not add any new expressive power 
to the I/O automaton model; moreover, it gives a particular transformation from forcing I/O 
automata to I/O automata. 

Proposition 4.6 Given a forcing I/O automaton A, consider an I/O automaton J- (A) where 

• states(J r (A)) = states(A) 

• start{T{A)) = start(A) 

• sig(T(A)) = (in(A), out(A), int(A) U {t p \ p G part(A)}) 

• steps(J r (A)) = steps(A) U {(q,T p ,q) \ p G part (A), q G (enabling(p)\force(p))} 

• part(/F(Aj) = {p U {t p } \ p G part(A)} 

Then ftraces(A) = ftraces(J-'(A)). 

Proof. Let (3 be a fair trace of A and let a be a fair execution of A such that trace(a) = (3. 
Build an execution a' of J~{A) from a in the following way: at each state of a add a self loop 
with all the t p actions that are enabled; if a is finite, loop forever on the final state of a by 
performing all the enabled t p actions in a Round-Robin way. Note that trace(a') = (3, so it is 
enough to show that a' is a fair execution of J~{A). Suppose that a' is not fair for J~{A). If a' 
is finite then there exists a class p of A with an enabled action from the last state of a' and 
such that t p is not enabled from the last state of a'. Also, a is finite and its last state enables 
an action from p. By definition of T the last state of a is in the forcing set of p, therefore 
a is not a fair execution of A; a contradiction. Suppose that a' is infinite and that there is 
a class p of A and a suffix a" of a' such that actions from p U {t p } are continuously enabled 
but never performed in a" . By definition of a' , t p is never enabled in a" , hence actions from 
p are always enabled and never performed in a". By definition of J 7 , all the states of a" are in 
the forcing set of p, hence there exists a suffix of a where actions from p are always enabled 
and never performed and whose states are all in the forcing set of p, i.e., a is not fair; again a 
contradiction. 

Conversely, let (3 be a fair trace of J~{A) and let a be a fair execution of J~{A) such that 
trace(a) = (3. Build an execution a' of A by removing from a all the transitions with actions 
of the form t p . Note that trace(a') = (3, so it is enough to show that a' is a fair execution of A. 

13 



If a is finite, then the last state of a does not enable any action from any class p, hence also 
the last state of a' does not enable any action from any class p, and a' is fair. If a is infinite 
and a' is finite, then, by definition of a' and J 7 , the last state of a' is not in the forcing set 
of any class p, hence a' is fair. If a is infinite and a' is infinite, then, for each class p, there 
are three possible cases. If states not enabling actions from p U {t p } appear infinitely often 
in a, then states not enabling actions from p appear infinitely often in a'; if actions from p 
appear infinitely often in a, then actions from p appear infinitely often in a'; if actions from 
p U {t p } appear infinitely often in a but actions from p appear finitely many times in a, then, 
by definition of J 7 , states not in the forcing set of p appear infinitely often in a'. In all of the 
above cases the conditions for a' to be fair are satisfied, therefore a' is a fair execution of A. ■ 

The standard operators of I/O automata can be easily extended to forcing I/O automata. The 
only nontrivial extension is that of the parallel operator, where the forcing set of each class has 
to be modified to take into account the states of the other forcing I/O automata. Consider for 
example a forcing I/O automaton A composed in parallel with a forcing I/O automaton B and 
let q be in the forcing set of some class p of A. Whenever A reaches state q in the composition 
A || B, we want the global state of A \\ B to be in the forcing set of p. Therefore all states of 
{q} X states(B) have to be in the new forcing set of p. 

Definition 4.7 (Composition of forcing I/O automata) The composition A = Yl i€l A, 
of strongly compatible forcing I/O automata {A; : i G 1} is the composition of their ordinary 
part augmented with new forcing sets as follows: for each class p £ part(pj), force(A)(p) = 

/orce(A_,-)(p)xn,- e /\j^.-- ■ 

Proposition 4.8 Given two forcing I/O automata A, B, 

1. J 7 (Hide I (A)) and Hide I (J 7 (A)) are the same I/O automaton; 

2. J 7 {A || B) and J- (A) || J-(B) are the same I/O automaton. 

Proof. The first statement is trivial since the hiding operator changes only the signature of 
an I/O automaton and the result of T does not depend on which actions of an I/O automaton 
are internal and which ones are external. For the second statement we verify that the two 
involved I/O automata are the same one by verifying each component separately. 

states{T{A \\ B)) = states(A \\ B) 

= states(A) X states(B) 

= states{T{A)) X states{T{B)) 

= states(/F(A) \\ T{B)) 

start (TiA \\ B)) = start(A \\ B) 

= start(A) X start {B) 

= start(J 7 (A)) X start(/F(Bj) 

= startlTiA) || F(B)) 
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out{T{A || B)) = out(A || B) = out(A) U out(B) 
= out(F(A)) U out(T(B)) 
= out(T(A) || T(B)) 



in{T{A || B)) = in(A || B) 

= (in(A) U in(B))\out(A \\ B) 

= (in{F(A)) U in{T{B)))\out{T{A) \\ T{B)) 

= in{T{A) || T{B)) 



int{T{A || Bj) = int(A \\ B) U {t p \ p £ part (A \\ B)} 

= int(A) U int(B) U {t p \ p £ part (A) U part(B)} 

= (int(A) U {t p I p £ part (A)}) U (int(B) U {t p \ p £ part(B)}) 

= int(T(A)) U int(T(B)) 

= int(T(A) || T(B)) 



part{T{A \\ B)) = {pU {t p } \ p £ part (A \\ B)} 

= {pU {t p } I p £ part (A) U part(B)} 

= {pU {t p } I p £ part (A)} U{pU {t p } \ p £ part(B)} 

= part (J 7 (A)) U part{T{B)) 

= part(T(A) \\ T(B)) 

The argument for steps is more complicated. Let ((q A , q B ) , a, (q' A , q' B )) £ steps(J r (A \\ B)). 
If a is not an action of the form t p , then ((q A ,q B ),a,(q' A ,q B )) £ steps(A || B). From the 
definition of the parallel composition operator and from the fact that steps(C) C steps(J r (C)) 
for each forcing I/O automaton C, it is immediate do derive that ((q A , q B ), a, (q' A , q' B )) £ 
steps(J r (A) || T{B)). If a is of the form t p , then suppose without loss of generality that 
p £ part (A). Then (q A ,q B ) £ enabling(p)\force(p) in A \\ B, and, by definition of paral- 
lel composition for forcing I/O automata, q a £ enabling(p)\force(p) in A. By definition of 
J 7 , (q A ,a,q A ) £ steps(J r (A)). By definition of parallel composition, ((q A , q B ), a, (q' A , q' B )) £ 
steps{T{A) || T{B)). 

Conversely, let ((q A , q B ), a, (q' A , q' B )) £ steps(J r (A) \\ T{B)). If a is not an action of the 
form t p , then a direct analysis of the definition of the parallel composition operator shows that 
((q A ,q B ),a,(q A ,q B )) £ steps(J r (A \\ B)). If a is of the form t p , then suppose without loss of 
generality that p £ part (A). By definition of J 7 , q a £ enabling(p)\force(p) in A. By definition 
of parallel composition for forcing I/O automata, (q A ,q B ) £ enabling(p)\force(p) in A \\ B. 
By definition of J 7 , ((q A ,q B ),a,(q A ,q B )) £ steps(J 7 (A \\ B)). ■ 
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4.2 Specification of the Components 

In Section 3.2 we described the system components using a "neutral" formalism that is not 
biased toward either verification method. Each of the two methods, however, has its own 
characteristic language for describing system components. In this section, we represent each 
element of Section 3.2 using a variant of the precondition-effect language of [LT87] that is 
suitable for describing forcing I/O automata. We also relate the new specifications to the 
neutral ones. 

In our precondition-effect language a forcing I/O automaton is described by means of its 
action signature, its states, its initial states, its transition relation, and its classes with forcing 
sets. The transition relation is specified by means of the preconditions for the execution of 
each action and the effect each action produces on the state. The precondition of an action 
gives the set of states from which it is enabled or from which it is expected; the effect gives the 
next state. If an input action occurs when its precondition is not satisfied, then the system 
moves to a special state S7. The state S7 implicitly has a transition to itself for each action and 
it does not appear in the forcing set of any class of local actions. 

Note that this representation can be more concise than the neutral representation, because 
states need not all be listed explicitly. Rather, they are described in terms of values of a 
collection of state variables. 

In order to simplify the notation we introduce an operator © on sets corresponding to the 
symmetric difference operator. Note that the transition relations of the forcing I/O automata 
we introduce below differ from those of Section 3.2 only in the definition of state S7. As a 
consequence, the specifications of this section and those of Section 3.2 denote I/O automata 
with the same set of fair traces. In fact, the connection between the I/O automata is much 
closer than this; we give a formal statement of the connection after the specifications. 

Specification 4.9 (Muller C element) A Muller C element Cp is defined as follows. 

5 = ({a,6},{c},0) 

g = {0,{a},{6},{a,6},fi} 

Qo = {0} 

P = {{c}} where {c} has forcing set {{a, b}} 

Transitions: 

Action a 

Precondition: q ^ {a, b} 
Effect: q':=q(Q{ a } 

Action b 

Precondition: q ^ {a, 6} 
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Effect: q' := q ® {b} 

Action c 

Precondition: q = {a, b} 
Effect: g' := 

Specification 4.10 (Majority element) A majority element M F is denned as follows. 

5 = ({a,6,c},{m},0) 
Q = 2^ a - b ^U{n} 

Qo = {0} 

P = {{to}} where {to} has forcing set {{a, 6}, {a, c}, {6, c}, {a, 6, c}} 

Transitions: 

Action a 

Precondition: q (j£ {{a, 6}, {a, c}} 
Effect: g' : =g©{ a } 

Action 6 

Precondition: g ^ {{a, &}, {6,c}} 
Effect: g' : =g©{&} 

Action c 

Precondition: g ^ {{a, c}, {6,c}} 
Effect: g':=g©{ c } 

Action m 

Precondition: \q\ > 2 
Effect: q' := {a,b,c}\q 

Specification 4.11 (Wire) A wire Wp is defined as follows. 

5 = ({m},{c},0) 
Q = {A, to, S7} 

g = {A} 

P = {{c}} where {c} has forcing set {{?«}} 

Transitions: 

Action m 

Precondition: q = X 
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Effect: q' := m 



ion c 






Precondition: 


q 


= m 


Effect: 


q' 


:= A 



Proposition 4.12 

1. A{Cjm) and T{Cp) denote the same I/O automaton. 

2. A(M N ) and T{M F ) denote the same I/O automaton. 

3. A{Wjm) and T{Wp) denote the same I/O automaton. 

Proof. The proof is a simple analysis of the definitions. We argue a bit more about the first 
statement and leave the other two to the reader. The states of A(C'n) and T{Cp) are the 
same since the states of Cp are those of Cjv plus S7 and A adds a new state S7 to the states 
of Cjv- Similarly, the start states are the same in A(C'n) and T{Cp). The partitions of the 
locally-controlled actions are the same since both Cjv and Cp have a unique class and both 
A and T add a new internal action t p to each class p. Similarly, the action signatures of the 
two I/O automata are the same. The transition relations of the two I/O automata are the 
same since the preconditions of the actions of Cp identify those cells of the transition table of 
Cjv that do not contain NS or NE, the effects of each action coincide in Cjv and Cp , all the 
states of Cp but S7 are in the forcing set of the unique partition of part(Cp), and A deals with 
unspecified inputs by moving to S7. ■ 

4.3 The Verification 

We finally prove that a Muller C element is implemented by a majority element and a wire. 
We first prove a proposition expressing this claim for forcing I/O automata. At the end of this 
subsection, we show how to derive the precise claim of Section 3.2. 

Proposition 4.13 Hide^ m j(M F \\ Wp) C F Cp, i.e., a Muller C element can be implemented 
by a majority element and a wire. 

Proof. We define a mapping from the implementation to the specification and show that 
it is a forward simulation. We then use the Execution Correspondence Lemma to obtain 
corresponding executions and use this correspondence to prove fair trace inclusion. 

More precisely, the mapping / to use is the following: 
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(0,A)^{0} 

({a}, A) ^ {{a}, ft} 

({&},A)~{{6},ft} 

({a,6},A)^{{a,6},ft} 

({c},m)h^ {{a, b}, ft} 

all other pairs i— ► {uj} 



We first prove that the above relation is a forward simulation. The condition on the initial 
states is immediate to verify since the initial state (0, A) is mapped to the initial state 0. For 
the transition relation we proceed by cases analysis on action names. 

Action a: We distinguish the following cases: 

• If a occurs from (x,X) where x £ {0,{a},{6}} then (x,X) — ► (x © {a}, A) and 

x — ► x © {a}. 

• If a occurs from ({a, 6}, A) then ({a, 6}, A) — ► (ft, A). Moreover {a, b} — ► ft and 
ft -%ft. 

• If a occurs from ({c},ra) then ({c},ra) — > (ft, to). Moreover {a, 6} — > ft and 
ft -%ft. 

• If a occurs from any state (x, A) where x ^ {0, {a}, {&}, {a, b}} then (ai, A) — ► (a;', A) 
and a;' <£ {0, {a}, {6}, {a, b}}. Moreover ft -% ft. 

• If a occurs from any state (ai, m) where x ^ {c} then (x, m) — > (x' , m) and ft — > ft. 
Note that, since for x = {a,c} we have x' = {c}, we need ft in the mapping for 
(|c},m). 

Action b: This case is the same as the case for action a. 

Action c: This action is enabled only from states of the form (x,m) and yields a new 
state (V, A). If x = {c} then x' = and {a, 6} — ► 0. In all other cases x' can be anything 
but 0. This is the case for which we need to map ({a}, A), ({&}, A) and ({a, 6}, A) to ft. 

Action to: This action is enabled from each state (x, A) and (x, m) with \x\ < 2. If the 
starting state is (x,m) then the final state is (V,ft). Moreover both starting and final 
states are mapped to ft. If the starting state is (x, A) with x ^ {a, 6} then the final state 
is (V,to) and both starting and final states are mapped to ft. If the starting state is 
({a, 6}, A) then ({a, 6}, A) — > ({c} 5 m ) an d both starting and final states are mapped to 
{a, 6} and ft. 

The existence of the above forward simulation allows us to conclude that each trace of 
Hide^ m j(M F \\ Wp) is a trace of Cp ■ We now use the same simulation to argue that each 
fair trace of Hide^ m j(M F \\ Wp) is a fair trace of Cp . Consider a generic fair execution a of 
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Hide^ m j(M F \\ W F ). By the Execution Correspondence Lemma, there is an execution a 1 oiC F 
corresponding to a through the mapping /. It is sufficient to argue that a' is fair to conclude. 

Suppose that a' is not a fair execution of C F . The only way the fairness for C F can be 
violated is for the states in a' to be {a, b} for some point on without c ever occurring. (In fact 
{a, b} is the only state in the forcing set for {c}.) Then in a, the correspondence says that the 
states are all either (ab, (f>) or (c, to) from that point on. If there is any occurrence of a (c, to) 
state, then the fairness condition for Wp says that eventually c occurs in a, so also in a', a 
contradiction. So the state must be (ab, (f>) forever. But then the fairness condition for M F 
says that eventually m occurs, changing the state to (c, ra), again a contradiction. ■ 

Note that the fairness part of the proof above is done somewhat less formally than the sim- 
ulation part; the fairness part can be formalized using a temporal logic of states and actions 
[Sta84, SLL93b]. 

Now we can give the main result: 



Theorem 4.14 Hide {m} (A(M N ) \\ A(W N )) Q F A(C 



N 



Proof. From Propositions 4.13 and 4.6 we derive J r (Hide^ m j(M F \\ W F )) Ef 3~{C f ). From 
Proposition 4.8 we derive H ide^ m j(J-'(M F ) \\ T{W F )) C F T{C F ). From Proposition 4.12 we 
obtain Hide {m} (A(M N ) || A(W N )) Q F A(C N ). ■ 

5 A Verification using Process Algebras 

In this section we carry out the verification required in Section 3.2 using process algebra. 
Again, we begin by presenting the relevant theory, then give new specifications, and finally 
carry out the steps of the proof. 

5.1 The Theory 

As before, our job is to prove a fair trace inclusion relationship between two I/O automata. In 
general, process algebra is not well suited for proving results about fairness, because fairness 
does not fit nicely into the theory of a process algebra containing recursion. However, process 
algebra can be used to reason about an approximation to fairness known as quiescence, and 
under certain circumstances, this may be enough. 

Below, we define quiescence and relate it to fairness. We then define DIOA ("Demonic I/O 
Automata"), a process algebra for proving quiescent trace inclusion relationships between I/O 
automata. 3 



The adjective "demonic" is used suggestively in [Seg92] to emphasize the fact that demonic I/O automata 
behave catastrophically in the presence of unexpected inputs. It is in contrast with the approach of [Vaa91] 
which is called "angelic" in [Seg92]. 
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5.1.1 From the Quiescent Preorder to the Fair Preorder 

Definition 5.1 (Quiescent executions and traces) A quiescent execution of an I/O au- 
tomaton A is a finite fair execution of A. A quiescent trace is the trace of a quiescent execution. 
We denote the set of quiescent traces of an I/O automaton A by qtraces(A). ■ 

Definition 5.2 (Quiescent preorder) Given two I/O automata A and B with the same 
external action signature, the quiescent preorder is defined as 

A Cq B iff traces* (A) C traces* (B) and qtraces(A) C qtraces(B). ■ 

The quiescent preorder was first introduced in [Vaa91] and is an attempt at approximating 
the fair preorder by only looking at the finite executions of an I/O automaton. As pointed 
out through some examples in [Seg92], the quiescent preorder is not an intuitively reasonable 
notion of implementation in general, however [Seg93] gives some sufficient conditions for the 
quiescent preorder to coincide with the fair preorder. Below we present some of the results of 
[Seg93]. We start with some definitions. 

Definition 5.3 (Quiescent detectability) An I/O automaton A is quiescent detectable if 
each finite fair trace of A is also a quiescent trace of A. ■ 

Quiescence detectability requires each divergence to be detected through a quiescent trace. 
The fair preorder, in fact, does not distinguish between divergence and quiescence, while the 
quiescent preorder does. 

Definition 5.4 (Quiescent continuity) An I/O automaton A is quiescent continuous if the 
limit of any chain of quiescent traces of A is a fair trace of A. ■ 

The quiescent preorder deals only with finite executions, while the fair preorder also considers 
infinite ones. A condition for the two preorders to coincide is that the information about 
infinite executions be captured by the information on the finite ones. To guarantee the above 
fact we also need finite internal nondeterminism. 

Definition 5.5 (Finite internal nondeterminism) An I/O automaton A has finite inter- 
nal nondeterminism (FIN) if V fteacts .( A) {g | 3 qoestar t(A)qo => q} is finite. ■ 

The above definition of FIN is weaker than the definition given in [LV91]. The definition 
of [LV91] requires, for every trace h, the set of reachable states with h to be finite. In our 
definition we only require a smaller set to be finite, i.e., the set of states reachable through h 
with its last external transition. 
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Definition 5.6 (Input quiescent detectability) An I/O automaton A is input quiescent 
detectable if each infinite fair trace of A with finitely many output actions has infinitely many 
prefixes that are quiescent for A. ■ 

An infinite fair trace made of input actions only can be obtained from an execution containing 
infinitely many internal transitions. The quiescent preorder, on the other hand, can detect 
only quiescent states. 

Theorem 5.7 (Relationship between the quiescent and fair preorder) Given two I/O 
automata Ai,A 2 with the same external action signature such that part (Ai) = {local(Ai)} and 
part(A 2 ) = {local(A 2 )} , if Ai is quiescent detectable and input quiescent detectable, and A 2 is 
fair continuous and has FIN, then 

Ai Cq A 2 implies A x C F A 2 . 

If A 2 is quiescent detectable then 

A\ C F A 2 implies A x Cq T 2 . ■ 

Quiescent detectability and FIN are generally met by practical systems. Note, in fact, that 
systems without any infinite internal computation are quiescent detectable. Also quiescent 
continuity is generally true. In [Seg93] it is shown that, if an I/O automaton has FIN and 
is input deterministic (for each state q and each input action a there exists a unique state q' 
such that q ===>■ q'), then it is quiescent continuous. It is not clear yet to us how general input 
quiescent detectability is. 

Theorem 5.7 shows how the quiescent preorder can capture the fair preorder of some I/O 
automata with a single class of locally controlled actions. This is not the case for general I/O 
automata. However, there are cases in which the quiescent preorder is sufficient for concluding 
fair trace inclusion in the presence of multiple classes. When an I/O automaton has more than 
one class of locally controlled actions, the quiescent preorder is not of great help in deriving 
the fair preorder. The following proposition is of help whenever the specification automaton 
has a single class and the implementation automaton has multiple classes. 

Proposition 5.8 Let A be an I/O automaton. If for each transition q — —^ q' of steps (A) 
where a is an input action and each class x of part (A), an action of x is enabled from q 1 if 
and action of x is enabled from q (i.e., input actions do not disable any class of part (A)), then 
ftraces(A) C ftraces(A') where A' differs from A only in that part (A 1 ) = {local(A)} . ■ 

If an I/O automaton A with multiple classes implements an I/O automaton B with a single 
class, and if the involved automata satisfy the conditions of Theorem 5.7, then the proposition 
above gives a sufficient condition for deriving the full fair preorder from the quiescent preorder. 
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In fact, from A' Cq B, where A' is the I/O automaton A with a single class, we derive A' C F B, 
and, from Proposition 5.8, we derive A C F B. Examples of systems satisfying the condition of 
Proposition 5.8 are the monotone I/O automata of [Sta90], which can model a large class of 
dataflow networks, and the semi-modular, speed-independent circuits of [MB59]. Our problem 
is based on delay insensitive circuits. 

5.1.2 The Calculus of Demonic I/O Automata 

The calculus of Demonic I/O Automata (DIOA) is a process algebra for I/O automata [Seg92]. 
Each I/O automaton is an expression which is obtained by applying operators to basic au- 
tomata. Each expression is sorted and each sort represents an external action signature. Each 
DIOA expression has a unique internal action r. Multiple internal actions, in fact, are used 
within I/O automata for expressing fairness with respect to different internal tasks; however, 
DIOA does not deal with fairness. In this paper we present a slightly modified version of DIOA 
in which we consider multiple internal actions. Each sort represents a full action signature with 
multiple internal actions. Our modification does not change the algebraic properties of DIOA 
(the axioms do not change), but it makes it easier to relate DIOA proofs to simulation proofs. 
We assume that the sort of each DIOA expression contains at least one internal action and we 
use t to denote a generic internal action. This assumption is necessary to model some of the 
operators. 

Table 1 contains all the operators of DIOA and Table 2 contains their operational semantics 
in terms of transition systems. The operators of DIOA recall the standard operators of CCS 
[Mil89]; however they are different in the sense that they also guarantee input enabling by 
moving an automaton to the state S7 whenever some unexpected input is provided. The 
expression nil models a quiescent automaton that moves to S7 for any input. The prefixing 
operator allows the specification of an automaton which first perform a specific action a. 
The internal choice operator models nondeterministic choice independently of the external 
environment. Particularly unfamiliar to the process algebraic community is the external choice 
operator, which is parameterized by two sets of input actions. The two parameters describe 
which arguments of the operator deal with different input actions. Consider the expression 
exp = a . e { a } + {6} b . f. The subexpression a . e is describing the behavior of exp in the presence 
of input action a while the subexpression b . f is describing the behavior of exp in the presence 
of input action b. The parameters are necessary since a . e also reacts to input b although that 
reaction is not desired. The meaning of an expression like a . e + b . /, however, is intuitively 
clear. Although this intuition is not expressible for general DIOA expressions, Table 3 defines a 
function si(e) (Specified Inputs) which is capturing our intuitive idea for DIOA expressions of 
the kind cii . e x + • • • a n . e n . Function si allows us to define an unparameterized choice operator 
by writing e + / for e sl ( e )-\- sl (j) f, where function si is defined in Table 3. The interested reader 
is referred to [Seg92] for a more detailed description of si and its generalization to all DIOA 
expressions. 

Given a DIOA expression, there is a natural way of associating an I/O automaton with it. 
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Name 



Op. Domain Range Restrictions 



quiescent 


nils 


A 


S 


omega 


n s 


A 


S 


prefixing 


a. s 


S 


S 


ichoice 


®s 


ij i l) 


S 


echoice 


-L s 


l) i l) 


S 


parallel 


Si\\s 2 


1S1, S 2 


S: 



a G ext(S) 

I,JC in(S) 

int(Si) fl acts(S 2 ) = acts(Si) Pi int(S 2 ) = 
tfSi) n out(S 2 ) = 



out(Si) fl out(S 2 ) = 



out(S 3 ) = out(Si) U out(S 2 ) 
(S 3 ) = (m(Si) U in(S 2 ))\out(S 3 
±(S*) = int(Si) Uint(Sn) 



in 



hiding 
renaming 

process 



T? 



PS 



S 
S 



X s A 



S' 

S' 

S 



iu\D 3 ) = \1n\D1) u iu\d 2 ))- 
int(S 3 ) = int(Si) U int(S 2 ) 

I C out(S), S' = (in(S), out(S)\I, int(S) U I) 

for each injective p : acts(S) — > acts(S') 
S' = {p{in{S)),p{out{S)),p{int{S))) 

X s G X s 



Table 1: The signature of DIOA 



We arbitrarily choose not to partition its locally controlled actions. In this way Theorem 5.7 
directly applies. 

Definition 5.9 Given a DIOA expression e, the associated I/O automaton V(e) is defined as 

• states(V(e)) = {e' \ 3t G acts(e)*,e — ► e'} 

• start (V(e)) = {e} 

• sig(V(e)) = (in(e),out(e),int(e)) 

• steps(V(ej) = {(e',a,e") | e' G states(V(e)),e' -^ e"} 

• part(V(e)) = {local (e)} ■ 

Proposition 5.10 Given two DIOA expressions e,f, 

1. V(Tj(e)) and Hidej(V(e)) are isomorphic I/O automata under the isomorphism h : 
states(V(Tj(e))) — ► states(Hidei(V(e))) such that /i(r/(e')) = e' ; 
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nil nils — ► &s Va G in(S) 

ome! £l s — > £l s a & ext(S) ome 2 Cls — > nils 



b 



pre! a . s e — > e pre 2 a . s e — > O5 V6 G ira(5)\{a} 

ichi ei ©s e 2 -^ ei ich 2 ei © s e 2 -^ e 2 



ich 3 ^ Va G in(S) ich 4 ^ Va G in(S) 

ei ©s e 2 — ► ei e : ffi s e 2 — ► e' 2 



g ; g' 

ech! ± Va G / U out(S) 



ei i+j e 2 



ech 2 §■ Va G J U out(S) 

ei /+j e 2 — ► e' 2 



ech 3 e 17 +fe 2 ^ft s Va e in(S)\(I\J J) 



e 9 — ► e. 



ech 4 5 r — ; 5 — ech 5 5 r — ; TT 

ei i + j e 2 — > ei 7 + } e 2 e : 7 +} e 2 — > e[ 7 +} e' 2 

a f a f 

e — ► e e — ► e 

taui rho 



par! 



rr e — > Tj e 



ei — > e e 2 — > e' 



S( p l\ , . p(a) 



M e ) — ► ^s(e') 



par 2 a G acts(Si)\ext(S 2 ) 

ei Sl \\s 2 e 2 — ► ei Sl \\s 2 e 2 



par 3 a G acts(S 2 )\ext(Si) 

ei Sl \\s 2 e 2 — > e x Sl \\s 2 4 



e — > e def 

rec 11 X = e 

X ^e> 



Table 2: The transition rules for DIOA. r is any internal action. 
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si(nil) = so(nil) = 

si'(O) = so{9) = out(tt) 

si(a . e) = {a} n in(e) so(a . e) = {a} n out(e) 

si(e 1 © e 2 ) = si(e 1 ) n s«( e 2) so ( e i © e 2) = «o( e i) U so(e 2 ) 

si(ei i+j e 2 ) = (/ l~l s«'( e i)) U ( J l~l s«'( e 2)) so ( e i / + J e 2) = so(e 1 ) U so(e 2 ) 

gj(X) = si(E(X)) so(X) = so(E(X)) 

Table 3: Definition of si and so for DIOA. 

2. V(e || /) and V(e) || 2>(/) are almost isomorphic I/O automata uder the isomorphism 
h : states(V(e || /)) -► states(V(e) \\ V(fj) such that h(e' || /') = (e',/'). T/ie onli/ 
difference is in that part(V(e || /)) = {local(e) U local (f)} and part(V(e) \\ V(f)) = 
{local(e), local(f)}. 

Proof. We give the proof for the hiding operator. The proof for the parallel composition 
operator is similar and is left to the reader. 

states(Hidei(V(e))) = states(V(e)) 

= {e 1 | It £ acts(e)*,e -U e'} 

= {Hnie')) | It e actsinie)), 17(e) -U r 7 (e') 

= {fe(r 7 (e')) | r 7 (e') G states(£>(r 7 (e)))} 

= /i(sfafes(D(r 7 (e)))) 



start(Hide I (V(e))) = start (V(e)) 

= M 

= h(start(V(T I (e)))) 



sigiHide^Vie))) = (in(V(e)),out(V(e))\I,int(V(e))U I) 

= (in(e),out(e)\I,int(e)U I) 

= (ira(r 7 (e)), 0Mi(r 7 (e)), mi(r 7 (e))) 

= (m(P(r 7 (e))), o^(P(r 7 (e))), m«(D(r 7 (e)))) 



26 



Ec 7 


Qmet(f) c and 






I 3 


7/(a . e) =q a . T/(e) if a ^ / 






I 4 


T/(e ff + K f) =q T/(e) ff + K T I {j) if so(e) n / = 


*>(/) n / = 


= 


In 


r 7 (i . e) = Q 77(e) if si'(e) = 







Table 4: Some axioms for the quiescent preorder of DIOA. 



steps(Hidei(V(e))) = steps(V(e)) 

= {(e', a, e") | e' G s<ates(X>(e)), e' -% e"} 

= {(%/(e')), a, /i(r 7 (e"))) | r 7 (e') G states^e)), r 7 (e') -^ r 7 (e")} 

= {(ft(r ; (e')), a, ^(^(e"))) | (r 7 (e'), «, r/(e")) G 8 tep 8 (V( Tl (e)))} 

part ( Hide jiVie))) = part(V(ej) 

= {local(e)} 

= {/oca/(r 7 (e))} 

= partiVinie))) 



The implementation relation for DIOA is the quiescent preorder, which is a weak congruence 
for all the operators but the unparameterized +. A weak congruence is a relation that is 
preserved under legal contexts, i.e., xlZy implies C[x] 1Z C[y] if C[-] is a legal context for both 
x and y. Table 4 contains some axioms for the quiescent preorder over DIOA. The axioms we 
present are just a some of those of [Seg92], however they are sufficient for our examples. They 
are sound in the sense that they state true properties of the I/O automata associated with 
the expressions. Axiom Ec 7 uses a function Quiet(f) which is true only if / is a quiescent 
expression, i.e., T>(f) enables only input actions in its start state. Ec 7 models the idea that, 
whenever a specification e does not say anything about some input actions, any choice of 
implementation / in the presence of those actions is correct. Axiom I 3 allows us to move 
external actions out of the hiding operator. Axiom I 4 uses a function so in its side condition. 
Function so (Specified Outputs) is defined in Table 3 and gives those output actions of its 
argument that can be performed up to internal transitions. The side condition for Axiom I 4 is 
necessary since an external choice context is not resolved with internal actions (see transition 
rules ech 45 ). Axiom I n allows us to eliminate initial internal computation from I/O automata 
whenever no input is expected (si(e) = 0). Two other important axioms deal with the parallel 
operator and with recursion. The expansion axiom allows to unfold a parallel expression into 
a nondeterministic sequential one; the recursive substitutivity rule states conditions for which 
a set of equations have unique fixpoint, and gives a method for proving that a process is 
implementing the fixpoint of a set of equations. In Section 5 the recursive substitutivity rule 
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plays a fundamental role. 

Proposition 5.11 (Expansion axiom) The following axiom is sound for the quiescent pre- 
order. 

E 2 Let e = ei || e 2 || • • • || e n where each e 8 - is of the form J2j a ij ■ e ij- Eor each action 
a G ext(e) let 

• _ j {eij | a t j = a} if a G acts(ei) 
a 1 {e t } otherwise 

Let out (a) be the index j such that a is an output action of j (0 otherwise) and let 

f if out(a) ^ and E° a ut ^ = 

a ~\ {/i || • • • || /„ : /•■ G ^ V (£• = A /,- = fi)} oi/ierrase 

Thene= Q Y, aeext(e) (J2feE a a -f)- ■ 

Theorem 5.12 (Recursive substitutivity) Let X = E(X) be a set of equations {Ei = 
J2j( a j -Xij)}, and let P be a set of BIO A expressions. If P Cq E[P/X] then P Cq X. ■ 

5.2 Specification of the Components 

In this section we specify the components of Section 3.2 using DIOA expressions. In this way 
we can use the DIOA axioms for the actual verification. The new specifications will explicitly 
consider only specified input actions at each state. The demonic approach guarantees the 
existence of a transition to S7 for each non-specified input action. The I/O automata of this 
section differ from those of Section 3.2 in the definition of S7. Since DIOA deals with finite 
and quiescent traces only, we need any fair trace of X>(S7) to be a quiescent trace of P(O), 
i.e., we need X>(S7) to be quiescent detectable. Quiescent detectability is obtained through 
the transition S7 — ► nil. Note that each sequence of external actions is a fair trace of P(O); 
moreover the I/O automata we specify in this section and those of Section 3.2 differ only in 
the transitions for state S7. As a consequence the specifications of this section and those of 
Section 3.2 denote the same objects in the sense that the corresponding I/O automata exhibit 
the same fair traces. A formal equivalence statement will be given after the specifications. 

Specification 5.13 (Muller C element) A Muller C element is specified as follows: 



c 


aei 

= a 


• c a + b . c h 


c a 


def 

= a 


■ C + b.C ai 


c b 


def 

= a 


■ C ai + b.C 


C a b 


def 

= C . 


,c 



where a, b are input actions and c is an output action. 
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def 


a 


def 


ah 


def 


abc 


def 



The DIOA specification of a Muiier C eiement is represented by the process variabie C . In 
order to be consistent with the specifications of the previous sections the process variable 
name should be Co, however, we decided to drop the parameter D to avoid confusion with the 
parameters of the other process variables. The subscripts in the process variables represent 
the input ports that have changed voltage level. When both the inputs have changed (state 
Cat) the output voltage level is changed. Note that in state C a j no inputs are accepted. The 
underspecification of the Muller C element in such cases is implicit in the structure of DIOA. 
Note that V(C) has FIN and is input deterministic. 

Specification 5.14 (Majority element) A majority element is specified by the following 
equations 

a.M a +b.M h + c.M c 

a.M + b.M ah + c.M ac 

m.M e + c. M abc 

m.M + a.M hc + b.M ac + c.M ah 

where a,b,c are input actions and m is an output action. The equations for M h ,M c ,M ac and 
M hc are similar to the equations above and can be easily derived. ■ 

The process variable M represents the majority element where the voltage levels of its input 
ports are the same as the voltage level of its output port. The process variables containing 
subscripts represent the majority element where only the voltage levels of the input ports not 
appearing as subscripts are the same as the voltage level of the output port. Note that the 
equation for M ah specifies that no inputs causing a variation in the output voltage level can 
occur when the output voltage level already has to change. If such inputs occur then the 
system implicitly moves to S7. 

Specification 5.15 (Wire) A wire is specified by the following equation: 

W d = m . c . W 
where m is an input action and c is an output action. ■ 

Proposition 5.16 A(C N ) = F V(C). A(M N ) = F V(M). A(W N ) = F V(W). 

Proof. We prove a stronger equivalence statement, namely that the involved I/O automata 
are isomorphic if we do not consider states S7 and nil. By observing that Proposition 3.5 
holds also for I/O automata associated with DIOA expressions (move to nil whenever it is 
possible) we complete the proof. We give the isomorphism for the Muller C element; the 
isomorphisms for the other elements are given in a similar way and are left to the reader. 
The isomorphism that we use for the Muller C element is h : states(A{C V)) — ► D(C) such 
that /i(0) = C, h({a}) = C a , h({b}) = Cj, and h({a,b}) = C a j. It is easy to check that h 
preserves the transitions of A(C'n) and V(C) if we do not consider transitions leaving from S7 
and transitions from/to nil. ■ 
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5.3 The Verification 

We now formally prove that a Muller C element can be implemented using a majority element 
and a wire. The implementation relation that we use is the quiescent preorder; however it 
is easy to verify that all the specified elements satisfy the hypothesis of Theorem 5.7 and 
Proposition 5.8, therefore we can conclude fair trace inclusion from quiescent trace inclusion. 
We first prove the statement concerning the quiescent preorder, the DIOA verification; then 
we show how the formal statement of Section 3.2 is derived. 

Proposition 5.17 "Tr m }(M || W) Cq C , i.e., a Muller C element C can be implemented using 
a majority element and a wire. 

Proof. We show that "Tr m }(M || W) Cq C . For doing that we consider a family of processes 
I, I a , lb, I a b where / = "Tr m }(M || W) and show that they satisfy the equations of C with Cq. 
It is then enough to use the recursive substitutivity axiom to conclude. 

By applying the expansion axiom and the hiding axioms we obtain 

/ = Q T {m] (M\\W) by expanding M\\W 

= Q T {m} ((a.M a +b.Mb + c.M c )\\(m.c.Wj) by Axiom E 2 

= Q T {m} (a.(M a \\(m.c.W)) + b.(Mb\\(m.c.W))) by substituting W for E{W) 

= Q T {m} (a.(M a \\W) + b.(Mb\\W)) by Axiom I 4 

= Q T {m} (a.(M a \\W)) + T {m} (b.(Mb\\W)) by Axiom I 3 

=q a . T {m} (M a \\W) + b . T {m} (Mb\\W) by definition of I a and I b 

= Q a .I a + b .I b 

where we define 

Ia = T {m] (M a \\W) 
Ib = T {m] (Mb\\W) 

With the same method we have 

I a = Q T {m} (M a \\W) = Q a . T {m} (M\\W) + b . T {m} (M ab \\W) = Q a . I + b . I ab 

and 

I b = Q T {m} (M b \\W) = Q a . T {m} (M ab \\W) + b . T {m] (M\\W) = Q a . I ab + b . I 

where we define 

I ai = T {m} (M ab \\W) 

We now proceed with the analysis of I ab . Step by step comments are below. 

I ab = q T {m} (M ab \\W) 

= Q T {m} (a . (n\\W) + b . (n\\W) + m . (M c \\c . W)) 
H Q T {m} (m.(M c \\c.W)) 
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= Q T {m] (m . (a . (M ac \\c .W) + b. (M bc \\c .W) + c. (M\\W))) 

Q Q T {m} (m.c.(M\\W)) 

= Q c.T {m] (M\\W) 

= Q C.I 

The first step follows the lines of the previous derivations by expanding process variables, 
applying the expansion theorem, and reconverting untouched expanded expressions to their 
corresponding process variable; the second step is an application of Axiom Ec 7 where inputs 
a and b are eliminated. According to the specification of C a) j, in fact, no input should occur 
before output c occurs. The expression on the second line specifies an implementation choice 
in the presence of inputs a and b while the expression on the third line does not specify any 
implementation choice. The third step is similar to the first one while the fourth step consists 
of successive applications of the hiding axioms. Action m is eliminated through Axiom I n and 
action c is brought outside the scope of the hiding operator through Axiom I 3 . The last step 
is a direct consequence of the definition of /. 

We can now apply the recursive substitutivity axiom and conclude T^ m j(M \\ W) Cq C. 
The fair trace inclusion follows from Theorem 5.7 and Proposition 5.8. All the involved I/O 
automata, in fact, are quiescent detectable, quiescent continuous, input quiescent detectable 
and have FIN. Moreover no input action disables any output action. ■ 



Theorem 5.18 Hide {m} (A(M N ) \\ A(W N )) Q F A(C 



N 



Proof. From Proposition 5.17, the soundness of the DIOA proof system, and Theorem 5.7, 
we derive V(T {m} (M\\W)) Q F V(C). From Proposition 5.10 we derive Hide {m} (V(M\\W)) Q F 
V(C). From Proposition 5.10 and Proposition 5.8 we have V(M)\\V(W) Q F V(M\\W), there- 
fore we derive Hide^ m j(V(M)\\V(W)) C F V(C). Finally, from Proposition 5.16 we derive 

Hide {m} (A(M N )\\A(W N )) Q F A(C N ). m 

6 Comparison of the Algebraic and the Simulation Techniques 

In this section, we compare the simulation and algebraic proof techniques for their usefulness 
in carrying out verifications of the sort outlined in this paper. The first thing to note is that 
both of the outlined proofs were fairly easy to carry out, once the machinery described in the 
"theory" sections had been developed. Naturally, people more familiar with one style of proof 
or the other will find it somewhat easier to use, but we did not find any appreciable difference 
for this example. The interesting question is whether both methods will scale equally well to 
a wide range of more complex examples. Here we think there are important differences and 
similarities, which we have tried to identify below. 
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6.1 Power of the Proof Method 

There is a strong similarity between our reasoning in the simulation proof and in the algebraic 
proof. It seems that the recursive substitutivity rule is used in this example somewhat as 
an algebraic version of the notion of forward simulation. That is, we consider the process 
variables of the set of equations comprising the specification as representing states of the 
specification. Then we consider the processes that we substitute for the process variables as 
representing states of the implementation that are related to the process variables for which 
they are substituted. 

This leads to the question of whether the simulation and algebraic methods we have used 
might not be equivalent in general; however, it turns out that they are incomparable. 

Let a, 6, c be output actions and consider the processes 

X d =a.b.X + a.c.X 

Y = a.(b.Y + c.Y). 

It is easy to prove that Y Cq a . b . Y+a .c.Y by using the axioms of [Seg92] and the recursive 
substitutivity rule; however there is no forward simulation from the transition system associated 
with Y and that associated with X . State Y, in fact, would be mapped to X . State b .Y + c.Y, 
instead, should be mapped to either b . X or c . X or both since Y can move with a only to 
those states. Unfortunately each of the choices above gives problems on the next transition. 

The difference between the systems X and Y arises when the decision about whether to 
perform b or c is made: X decides before Y. A forward simulation between two processes A 
and B exists only if B does not decide before A. Y can be proved to implement X by using a 
different simulation technique based on a notion of backward simulation [LV91]. However, there 
are also examples that can be proved using DIOA deductions but not by backward simulations. 
One example is 

X d = a . c . X + b . Z Z = c.X 

Y = a.Z' + b.Z' Z' = c.Y 

where a, b and c are output actions. It is easy to algebraically show that Y and Z' satisfy the 
equations for X and Z, however there is no backward simulation from Y to X . 

There are also cases in which there is a forward simulation between two processes but 
quiescent trace inclusion cannot be proved using DIOA, because the recursive substitutivity 
rule cannot be applied. Consider, for example, the processes 



X = a . X and X; = a . X, 



+1 



for an infinite set of process variables X, : i £ N. The mapping that maps each X, into X is 
trivially a forward simulation from X to X; however, since none of the given equations relates 
some Xi to Xj with j ' < i, we cannot prove that X < a . X , so the recursive substitutivity 
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rule does not apply. The above mapping is also a backward simulation from X to X , therefore 
also backward simulation is incomparable with DIOA deduction. 

All the examples above also work for the simple trace preorder. The reader is referred to 
[DS92] for its axiomatization. 

6.2 Treatment of Fairness 

In the given example, a separate argument about fairness is made in the simulation proof, 
whereas no such argument is needed in the algebraic proof. In the given algebraic proof, fair 
trace inclusion is a consequence of quiescent trace inclusion, and the deductions within DIOA 
are strong enough to prove quiescent trace inclusion. However, the algebraic framework, as it 
stands, does not provide a fully general model for proving fair trace inclusion: the connection 
between the quiescent and fair preorders holds only under some special conditions. We argued 
in Section 5.1.1 that the properties of quiescent detectability, finite internal nondeterminism 
and quiescent continuity seem to be sufficiently general for representing physical systems; 
on the other hand we do not have a clear idea yet about the generality of input quiescent 
detectability. An example of a non-input quiescent detectable device is an infinite buffer which 
performs some internal update after receiving some input. An infinite fair execution leading 
to an infinite trace with input actions only can be obtained by interleaving each input with 
the internal update, however, if the buffer enables some output whenever it is not empty, no 
finite sequence of input actions is a quiescent trace. 

For systems in which these properties fail, it is unclear how to use the algebraic approach to 
reason about fair trace inclusion. It is worth remarking that all the DIOA axioms presented in 
[Seg92] except for the recursive substitutivity rule are sound for the fair preorder as well as the 
quiescent preorder. (The recursive substitutivity rule is sound for all I/O automata satisfying 
the conditions of Theorem 5.7.) So if we deal with non-recursive definitions, the axioms for 
DIOA provide a method for directly proving fair trace inclusion. However, this is of limited 
use since almost any nontrivial I/O automaton contains loops that have to be specified using 
recursion. Even our small example cannot be specified without using recursion. 

It is also unlikely that a result similar to the Execution Correspondence Lemma could 
be used together with an algebraic proof. Even by axiomatizing a different preorder relation 
such as "existence of a forward simulation" , an algebraic proof would prove the existence of a 
simulation without exhibiting it. The fairness part of our simulation proof, on the other hand, 
is strongly based on the actual forward simulation from the implementation to the specification. 
The simple knowledge that a forward simulation exists is not sufficient. It is possible that new 
techniques, perhaps based on the structure of an algebraic proof, could be developed, but this 
remains to be done. 

The generality of our approach to fairness in the simulation proof also remains to be 
considered; however, in this case there is already good evidence that this approach works well 
in practice [LS92, SLL93b]. The approach based on the Execution Correspondence Lemma 
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provides a convenient way to base a fairness proof on a simulation proof; it may be that there 
are some fairness proofs that are inherently unable to be split in this way, but we do not know 
of any such examples. The use of forcing conditions provides a useful generalization of the 
usual I/O automaton fairness notion, but it seems likely to us that further generalizations will 
be required in order to describe some realistic liveness requirements. What those extensions 
might be, and whether they will work well in conjunction with the Execution Correspondence 
Lemma, remain to be seen. 

Note that the arguments of this subsection only hold for fairness sensitive semantics such 
as the semantics of I/O automata. If the semantics is not based on a fairness sensitive relation, 
then the problems of this subsection disappear. Examples of non fairness sensitive relations 
are bisimulation [Mil89] and testing [DH84, Hen88]. 

6.3 Representation of Automata 

The two different proof methods typically use very different ways of representing automata, 
each best suited for carrying out the corresponding type of proof. In order to give a fair 
comparison between the two methods, we began with a neutral representation, which is basi- 
cally just a state-transition table that enumerates the results of all transitions performed in all 
states. We then gave two other representation methods, and asserted their equivalence with 
the neutral method. 

The precondition-effect language represents an automaton in an action-based way. That is, 
the information associated with each action is given in one place; this information consists of 
the set of enabling states and the allowed transitions for that action. In terms of the neutral 
representation, we can think of this language as presenting the automaton by columns. 

On the other hand, DIOA represents an automaton in a state-based way. That is, the 
information associated with each state is given in one expression; this information consists of 
a list of the enabled transitions from that state. We can think of this language as presenting 
the automaton by rows of the neutral automaton. 

In our small example, the state-based method gives a more elegant and concise represen- 
tation of the circuits than the action-based method, but this will not be true in general. The 
choice of which representation is better will vary among different automata, depending upon 
whether the automaton table is most easily described by columns or by rows. Our experi- 
ence shows that, for complex systems, the action-based description is usually the better one 
[SLL93b]. 

There is one main reason for this. The states of a complex automaton can usually be 
described in terms of a small number of state variables or data objects, which permits a 
description to be parameterized by the values of those objects. A typical complex automaton 
exhibits locality of activity: each action typically involves only a small portion of the state, i.e., 
its occurrence depends on the values of a small number of data objects, and its results affect 
only a small number of objects. This locality leads to concise descriptions for each action, 
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but it is unclear how a state-based description might take advantage of it. Note that parallel 
decomposition cannot be used in general to describe this kind of locality. 

Although the action-based representation method generally works better than the state- 
based one, there is complete freedom in the choice of the representation style for an I/O 
automaton whenever a simulation proof technique is used, i.e., it is always possible to use a 
description language like the state-based one in conjunction with assertional reasoning. On the 
other hand the description language for DIOA is strictly determined by the algebra itself, so 
there is apparently no way to use an action-based representation method in process algebras. 
Moreover, the pure DIOA calculus does not provide tools to deal with structured states. 

A standard technique to deal with structured states within process algebras makes use 
of parameterized process variables [Hoa85, Mil89, Bae90]. For example, a counter can be 
represented by a process variable X parameterized over a natural number n in the following 
way: 

X = up . X x 

def 

X n = down . X n _i + up . X n+ i if n > 0. 

Such a technique is generally used when the size of a system is large [Bae90, OP92] since a 
specification would become unreadable otherwise. Our example, although small, makes use of 
parameters. It is also possible to add standard programming languages constructs and define 
a new equation of the form 

X n = up . X n+ i + (if n > then down . X n _i). 

By means of the above ideas it is possible to directly encode an action-based represented 
automaton A into DIOA. The encoding consists of one process variable X parameterized over 
states(A). The equation for X is then of the form 

if precondition(di) then effect(di) else 
if precondition(a 2 ) then effect (a 2 ) else • • • 

Unfortunately, the more structure we add to the algebraic notation, the more complicated 
it is to apply the DIOA axioms to carry out a proof. Also, the recursive substitutivity rule 
requires one to find a set of processes that satisfy a given set of inequations. When states 
are parameterized, finding those processes is often tantamount to finding a simulation relation 
between states of the implementation and states of the specification, which is consistent with 
the initial observation of Section 6.1. In this case, the task of applying the axioms becomes the 
equivalent of proving that a given simulation is a forward simulation. For example, consider 
the counter we specified before and consider an implementation as follows: 

Yio = up . Xn 

def 

X n = down . X n _i + up . X n+ i if n > 10. 

The recursive substitutivity rule requires us to show that each Yi satisfies the equation for 
Xi_ w . The association h : Yi i— ► Xi_ w is a sort of simulation, and the algebraic proof shows 
its correctness. 
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6.4 Mechanization 

The process of carrying out either a simulation proof or an algebraic proof can be long and 
tedious, and therefore error-prone, when the involved automata are large. A simulation proof 
typically involves a cases analysis based on actions; each case involves logical deduction based 
on descriptions of the state transitions in both the implementation and specification automata 
and on a description of the forward (or other kind of) simulation relation. An algebraic proof 
involves a series of deductions using the algebraic axioms. In both cases, it should be possible 
to check the correctness of the deduction steps using an automatic prover. However, we would 
also like some help from an automatic prover in actually carrying out these tedious steps. 

An automatic prover can help in the production of a simulation proof, but we do not expect 
that the proof process will be completely automatic since the problem is undecidable in general. 
In addition to descriptions of the two automata, the writer of such a proof will have to provide 
a description of the simulation relation and possibly some invariances. Once this information 
is provided, an automatic prover can be used to help in filling in enough details to verify that 
the simulation is correct. As described in [SGG + 93], the Larch prover has been successfully 
used for this purpose. Also the theorem prover Isabelle was used for the same purpose in 
[Nip89]. The work on mechanical simulation-based verifications is still under development, 
and [Nip89, SGG + 93] are just the first attempts at solving the problem. 

It seems unlikely that an automatic prover will be of much help in defining the simulation 
relation in a simulation proof. In small cases, essentially when there are finitely many states 
as in our example, a model-checking approach might be helpful. The task of defining the 
simulation relation by hand will often not be easy; its difficulty is comparable to that of defining 
an invariant assertion. However, usually the designer of a system has enough intuitions about 
the design to be able to define a relation that is almost correct, and this can be used as a 
starting point for constructing the correct relation. 

In the process algebraic proof given in this paper the axioms that have to be applied during 
each step are partially determined by the equations defining the specification automaton. Our 
proof steps were essentially repeated applications of the expansion axiom followed by some 
simplifications based on the given specification. This heuristic is generally applicable when 
dealing with (finite state) circuit descriptions. It is also applied in [Jos92, Seg92, OP92] and 
in several of the examples of [Bae90]. In these cases, algebraic manipulators like those of 
[MV91, Lin91] can be used. However, when the problem becomes large or is described by 
an infinite state machine, the remarks at the end of Section 6.3 show that some form of 
simulation has to be defined even for an algebraic proof, therefore the difficulties involved in 
the mechanization of simulation and algebraic proofs are comparable. 

6.5 Additional Benefits Obtained from the Proof 

Experience with large simulation-based verifications [WLL88, LP92, SLL93b] has shown that 
the formal description of the simulation relation in a simulation proof constitutes an important 
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piece of documentation of the key ideas of the implementation, in much the same way that an 
invariant assertion does; invariants and simulations typically express the key intuitions that 
make the implementation work. Similarly, due to the remarks at the end of Section 6.3, an 
algebraic proof can embed some form of mapping which can be used as a documentation. 

Because of the Execution Correspondence Lemma, a simulation-based proof provides a cor- 
respondence between executions rather than just trace inclusion. This correspondence enables 
us, for example, to base proofs of fairness on proofs of ordinary trace inclusion. A process al- 
gebraic proof, on the other hand, proves only the properties for which the axioms are certified 
to be sound. In our example we were able to prove liveness because the quiescent preorder 
coincides with the fair preorder under some particular conditions; however, if those conditions 
are not met, or if we need to prove other properties (e.g., based on forcing sets) the algebraic 
proof provides no help. 

In our experience simulation proofs are flexible in the sense that a given proof can usually 
be modified fairly easily in order to verify new properties of an implementation. A typical 
verification task, for example the one in [SLL93b], involves the definition of specification and 
implementation automata and the proof that the implementation meets the specification. Dur- 
ing the proof some errors might be discovered and the involved automata might need to be 
modified. Also, after the proof is completed, the specification and/or implementation automata 
might be slightly modified in order to make them cleaner and more general. The simulation 
relation and the correctness proof might then have to be correspondingly modified. In general 
the structure of the simulation proof seems to provide us with a lot of guidance in carrying 
out such modifications, since its general structure is usually preserved. To the extent that 
an algebraic proof embeds a simulation proof, the same advantages for modifiability would 
accure. 



7 Conclusion 

Using a simple example based on delay insensitive circuits, we have compared two widely used 
verification techniques for concurrent and distributed systems. The assertional methods based 
on I/O automata have been successfully used for the verification of very complex systems 
[LT87, WLL88, LP92, SLL93b] while the algebraic techniques of process algebras [Mil89] have 
generally been used for relatively small examples [Bae90, Jos92]. 

We have verified the correctness of the implementation of a Muller C element taken from 
[Jos92] both in the assertional framework and in the process algebraic framework. The algebraic 
proof is based on DIOA [Seg92], a process algebra for I/O automata. 

The example we have used is one of the typical examples of the process algebraic community; 
therefore, it should not be surprising that the process algebraic analysis looks shorter than the 
simulation-based one. Starting from the presented example, however, our discussion has shown 
that scaling algebraic proofs to more complex systems leads to the use of simulation-based 
verification techniques. 
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Although we have emphasized verification in this paper, it is important to remember that 
verification is not the only purpose, nor even the main purpose, of process algebra. Rather, 
process algebra is intended to provide compositional semantics for programs. Of course, one 
important use for such a semantics is to provide a basis for carrying out formal correctness 
proofs for systems. Since one of the most practical verification methods is simulation, it is 
important that an algebraic semantics be designed with a view toward compatibility with 
simulation proofs. Given a program that is supposed to implement a given specification, 
a process algebraic characterization of the semantic model can be used to compositionally 
compute the semantics of the given program, then a simulation-based technique can be used 
to prove the correctness of the implementation. Perhaps, we could also add an intermediate 
step in which the meaning of a program is algebraically simplified before starting with the 
assertional part of the correctness proof. 
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